This page last changed on Jan 02, 2006 by scytacki.

Configuration Schemas

Linux and other OSes could benfit from configuration schemas. Many people understand this: (insert examples as proof), but it hasn't happened for one reason or another.

Why it hasnt happened yet?

I think the main reason is that developers understand the benfits but the benifits aren't significant enough for them to provide the motivation for implementation. The real benifits go to end users, and documentation maintainers. However often these people don't have the structured data background to see the benifits of a standard schema system.

What are the benifits?

  1. Configuration files can be verfied without restarting/affecting the program they are configuring. Apache uses an example of this. (others?)
  2. They provide perfect hooks to hang documentation about configuation. Apache (others?) already document the config files in a form very similar to a schema. I don't believe that is tied to the actual schema used by apache-cfg. (or whatever the program is called). This structured documentation can be turned into man pages, info pages, web pages, example config files with documentation in comments.
  3. An configuration editor can be used that only creates valid (to a point) configurations, and provides integrated help about configuration options. Examples of these editors are the linux kernel configuration editor. Another example is the gentoo configuration editor.
  4. makes creating wizard configuration editors, or cross platform configuartion editors much easier.

Not Another Wizard Configuration

Wizard like configuration is necessary to make linux easier to use. But the current state of linux configuration makes this impossible. The problem is the whole system can't be configured this way because there are too many options. I believe this relative lowlevel schema approach will form a base which wizard configurations can build on. However this system isn't just a building block. It is an incremental improvement on text files. The fact that most linux sys admins still use configuration files (proof?), so wizard configuation isn't necessary for many people. However I believe if there is a small amount of scafolding (structure) around these configuration files, that is enough to help the current linux sys admins, and to make linux easier to use by newbies.

In the original Config4GNU article, editing the configuration in a tree like structure is avoided because it isn't any better than just using config files. And the article correctly says it is worse because it doesn't have contextual comments. Editing in a tree like structure is the goal of this approach but with two important scafolds:

  • comments - documenation about each option
  • options are limited by a schema.

I was at a talk by one of the leads on the webim project. When he was asked about when the linux providers would be able to configure most of the os, his answer basically was, "when all the config files are the same". But most every distribution and software project has a different way of configuraiton itself, and I don't think that is going to every change. So it is impossible to have a single UI (graphical or otherwise), for configuring them. I agree it is impossible now, but I disagree that all the files need to be the same. If all the files had schemas and a common language/api for manipulating them, then writing and maintaining a single generalized ui (wizard) would be feasible.

Relation to other Configuration Technologies

  • CIM
  • Config4GNU (CFG)
  • Wizard Configuration - WebMin, gnome-admin, (more...)
  • Registry, (gnome equivalent)
  • Config file version control (gentoo process of updating config files) (refernce article about using cvs for config files)

Sustainability - Who?

  • The best author is the group that is maintaining the program being configured. - This task should be a natural for them due to the benifits listed above. Many projects are already doing it (apache, ...), but there is not a shared set of tools and formats, and they aren't documented well enough for other projects to beginning using them.
  • Another author is a distribution package maintainer (gentoo, debian, red hat). There is generally a group responsible for
    packaging a program to be installed in a distrubtion. Many times this group provides startup config files, or eample config files. In addition, or instead they could provide this in the form of a schema with documentation and defaults.
  • General documenation project (LDP, ...) in addition to providing a howto or man page for a particular, a schema for the related config files can be provided.
  • End User. If a user wants to document their reason for chaning a configuation file that should be handled. Or if they have a program that doesn't have a schema or documenation they can create it locally first.

What is needed?

Libraries, Tools, Shared Public Archives,

  • Documenation Editors.
  • config file validity checkers
  • translation programs (xsl...) to convert from the documenation in the schema to the output docuementation
  • Configuration Editors with context help.
  • One or more community web site for providing a place to store, find, and discuss user contributed schemas.
  • common location for program contributed schemas - this isn't required but it would make it easier.

New Standards?

  • define existing configuration file types.
  • Do all the schemas need to be maintained in the same format - no. But at least they need to be structured in a way that can be converted to a standard format. Otherwise, benifits 3 and 4 won't be possible. If the schema is maintained in a non standard form then standard documenation editors can not be used.

DeveloperWorks Links

Document generated by Confluence on Jan 27, 2014 16:56